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CarnegieMelkm 

Software  Engineering  Institute 

Objectives 

Start  to  forge  a  more  detailed  and  shared 
understanding  of  the  interpretation  of  “high 
maturity”  and  “high  capability”  practices. 

Build  consensus  on  how  to  handle  model 
interpretation  for  courses  and  appraisals. 

Increase  the  understanding  of  specialized 
knowledge  associated  with  accurately  explaining 
and  appraising  implementations  of  higher  levels  of 
maturity  and  capability. 
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CarnegieMelkm 

Software  Engineering  Institute 

What  We  Will  Do  Today 

•  Briefly  review  some  standard  material  about  model 
content  and  interpretation 

•  Describe  areas  where  ambiguity  exists  today 

•  Discuss  competing  interpretations  of  key  topics 

•  Seek  opinions  and  experiences  from  Lead  Appraisers 
and  Instructors  to  serve  as  memorable  examples  for 
others 

•  Document  needs  for  future  work  to  forge  a  more 
consistent  interpretation  and  application  of  CMMI 
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CarnegieMelkm 

Software  Engineering  Institute 

What  We  Will  NOT  Do  Today 

•  Provide  a  complete  cookbook-style  solution 

•  Resolve  all  actual  or  perceived  problems  in  the  model 
or  appraisal  method 

•  Seek  out  and  penalize  Lead  Appraisers  and  Instructors 
who  have  different  interpretations  of  the  model  or  the 
method 

•  Provide  all  attendees  with  the  necessary  knowledge 
and  competencies  to  be  experts  on  these  topics 
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CarnegieMelkm 

Software  Engineering  Institute 

Ground  Rules 

•  The  person  at  the  podium  is  not  the  ultimate  authority 
on  these  complex  topics 

•  We  are  here  to  work  together  to  gain  insight  from 
listening  to  each  other  and  sharing  our  views 

•  Real  world  examples  are  much  more  helpful  than 
hypothetical  scenarios  -  please  try  to  work  with  facts 

•  Plan  to  work  and  contribute,  not  sit  back  and  soak  it  in 
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GimegfeMeHoii 

Software  Engineering  Institute 

Schedule  For  The  Day 
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CarnegieMeUan 

Software  Engineering  Institute 

Challenge  Questions  to  Ponder 

•  How  many  critical  subprocesses  have  to  be  statistically 
managed  in  order  to  qualify  for  Maturity  Level  4? 

•  In  order  to  qualify  for  Maturity  Level  5,  do  the 
processes  changed  using  OID  have  to  have  previously 
been  statistically  managed?  Quantitatively  managed? 

•  What  business  drivers  might  lead  an  organization  to 
want  to  raise  OID  to  Capability  Level  5?  How  about 
other  process  areas  at  CL4  or  CL5  -  what  are  the 
typical  “Capability  Profiles”  and  the  business  drivers 
that  motivate  them? 
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CarnegieMeUan 

Software  Engineering  Institute 

Challenge  Questions  -  2 

•  In  order  to  qualify  for  Maturity  Level  4,  is  it  sufficient  to 
use  control  limits  that  are  derived  from  organizational 
baselines  and  not  project  data? 

•  Does  statistical  management  of  critical  subprocesses 
that  operate  across  projects  qualify  for  Maturity  Level  4? 
For  example,  the  procurement  process  or  the  DAR 
process. 

•  Is  it  sufficient  to  apply  statistical  management  to  a 
single  attribute  of  a  critical  subprocess,  in  order  to 
qualify  for  Maturity  Level  4? 


©  2005  by  Carnegie  Mellon  University 


page  9 


CarnegieMelkm 

Software  Engineering  Institute 

Challenge  Questions  -  3 

•  Is  it  reasonable  for  an  appraisal  scoped  to  a  single 
project  to  yield  a  Maturity  Level  rating  of  4  or  5  -  in  an 
organization  where  multiple  projects  are  underway? 

•  Should  we  establish  different  qualifications  for  Lead 
Appraisers  who  perform  appraisals  that  result  in 
Maturity/Capability  Level  ratings  above  3? 

-  What  specific  skill/knowledge  do  they  need? 

-  How  should  this  be  acquired  or  assured? 

•  Should  different  standards  of  data  or  organizational 
sampling  be  applied  to  appraisals  focused  above 
Maturity/Capability  Level  3? 
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CarnegieMelkm 

Software  Engineering  Institute 

Ground  Rules  for  Afternoon  Sessions 


•  The  goal  is  active  learning  through  participation,  not 
passive  listening.  Please  be  prepared  to  work. 

•  Each  breakout  session  will  have  a  facilitator,  note-taker, 
and  reporter.  We  are  looking  for  volunteers. 

-  Facilitator  manages  the  interaction 

-  Note-taker  records  important  results 

-  Reporter  presents  the  results  to  the  larger  group 

•  Use  this  morning  to  think  about  which  topic  you’d  like 
to  dig  into  more  deeply  -  one  of  the  challenge 
questions,  or  something  you  suggest  during  break. 
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Level  4  Practices 


Carra^MeUon 

Software  Engineering  Institute 


Management  by  Rear-View  Mirror 


Most  use  of  measurement  in  low 
maturity  organizations  is  purely 
retrospective. 

Overly  narrow  view  -  contextual 
data  fades  from  memory  quickly. 

Correcting  yesterday’s  wrong 
turns  -  it  is  difficult  to  ask  “what 
if  we  do  something  different?” 
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Carra^MeUon 

Software  Engineering  Institute 


Maturity  Level  4 


At  A  Glance 


“Localization  Parameters” 
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CarnegieMelkm 
Software  Engineering  Institute 

Organizational  Process  Performance 

The  purpose  of  Organizational  Process  Performance  is 
to  establish  and  maintain  a  quantitative  understanding 
of  the  performance  of  the  organization’s  set  of 
standard  processes  in  support  of  quality  and  process- 
performance  objectives,  and  to  provide  the  process 
performance  data,  baselines,  and  models  to 
quantitatively  manage  the  organization’s  projects. 
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CarnegieMeUan 
Software  Engineering  Institute 

Specific  Goal  for  OPP 

SG  1  -  Establish  Performance  Baselines  and  Models 
Baselines  and  models  that  characterize  the  expected 
process  performance  of  the  organization's  set  of 
standard  processes  are  established  and  maintained. 
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CarnegieMelkm 

Software  Engineering  Institute 

Specific  Practices  for  OPP 

SP1.1  -  Select  the  processes  or  process  elements  in  the 
organization's  set  of  standard  processes  that  are  to  be 
included  in  the  organization's  process  performance 
analyses. 

SP1.2  -  Establish  and  maintain  definitions  of  the  measures 
that  are  to  be  included  in  the  organization's  process 
performance  analyses. 

SP1.3  -  Establish  and  maintain  quantitative  objectives  for 
quality  and  process  performance  for  the  organization. 

SP1.4  -  Establish  and  maintain  the  organization's  process 
performance  baselines. 

SP1.5  -  Establish  and  maintain  the  process  performance 
models  for  the  organization's  set  of  standard  processes. 


©  2005  by  Carnegie  Mellon  University 


page  17 


GarnegieMelkm 

~  Software  Engineering  Institute 

Modeling  the  Life  Cycle 

Decomposing  the  life  cycle  of  a  project,  it  can  be  viewed  as  a  set  of 
inter-connected  processes  -  each  with  it’s  own  capacity,  throughput, 
productivity,  magnitude,  defect  introduction  rate,  defect  removal  rate... 
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CarnegieMelkm 

Software  Engineering  Institute 

Specific  Practices  for  OPP 

SP1.1  -  Select  the  processes  or  process  elements  in  the 
organization's  set  of  standard  processes  that  are  to  be 
included  in  the  organization's  process  performance 
analyses. 

SP1.2  -  Establish  and  maintain  definitions  of  the  measures 
that  are  to  be  included  in  the  organization's  process 
performance  analyses. 

SP1.3  -  Establish  and  maintain  quantitative  objectives  for 
quality  and  process  performance  for  the  organization. 

SP1.4  -  Establish  and  maintain  the  organization's  process 
performance  baselines. 

SP1.5  -  Establish  and  maintain  the  process  performance 
models  for  the  organization's  set  of  standard  processes. 


©  2005  by  Carnegie  Mellon  University 


page  19 


GarnegieMelkm 

~  Software  Engineering  Institute 

Importance  of  Operational  Definitions 

Establishing  sufficient  definitions  of  measures  used,  and  ensuring  their 
consistent  application  is  one  of  the  early  challenges  that  organizations 
face  when  moving  to  level  4. 


#  include  <stdio.h> 

#  include  <stdlib.h> 

II  This  program  prints  “Hollow  world”  to  the  screen. 
main() 

{ 

printf(“Hollow  world“); 

} 

1  2  3  4  5  6  7 
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CarnegieMelkm 

Software  Engineering  Institute 

Specific  Practices  for  OPP 

SP1.1  -  Select  the  processes  or  process  elements  in  the 
organization's  set  of  standard  processes  that  are  to  be 
included  in  the  organization's  process  performance 
analyses. 

SP1.2  -  Establish  and  maintain  definitions  of  the  measures 
that  are  to  be  included  in  the  organization's  process 
performance  analyses. 

SP1.3  -  Establish  and  maintain  quantitative  objectives  for 
quality  and  process  performance  for  the  organization. 

SP1.4  -  Establish  and  maintain  the  organization's  process 
performance  baselines. 

SP1.5  -  Establish  and  maintain  the  process  performance 
models  for  the  organization's  set  of  standard  processes. 
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CarnegieMelkm 
Software  Engineering  Institute 

Interplay  of  Quantitative  Objectives 

Quantitative  objectives  for  the  quality  and  performance  are  not  as  easy 
to  set  as  typical  ‘balanced  scorecard  goals.’  The  interrelationships 
among  the  objectives  form  the  basis  for  a  project  management  strategy. 


▲ 


Quality 
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CarnegieMelkm 

Software  Engineering  Institute 

Specific  Practices  for  OPP 

SP1.1  -  Select  the  processes  or  process  elements  in  the 
organization's  set  of  standard  processes  that  are  to  be 
included  in  the  organization's  process  performance 
analyses. 

SP1.2  -  Establish  and  maintain  definitions  of  the  measures 
that  are  to  be  included  in  the  organization's  process 
performance  analyses. 

SP1.3  -  Establish  and  maintain  quantitative  objectives  for 
quality  and  process  performance  for  the  organization. 

SP1.4  -  Establish  and  maintain  the  organization's  process 
performance  baselines. 

SP1.5  -  Establish  and  maintain  the  process  performance 
models  for  the  organization's  set  of  standard  processes. 
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Carra^MeUon 

Software  Engineering  Institute 

Process  Performance  Baselines 


Process  performance  baselines  need  to  be  identified  with  the 
contextual  factors  that  permit  appropriate  future  interpretation  of 
the  data.  Highly  aggregated  data  sets  with  multiple  common  cause 
systems  are  not  very  usable  in  the  context  of  QPM. 
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CarnegieMelkm 

Software  Engineering  Institute 

Specific  Practices  for  OPP 

SP1.1  -  Select  the  processes  or  process  elements  in  the 
organization's  set  of  standard  processes  that  are  to  be 
included  in  the  organization's  process  performance 
analyses. 

SP1.2  -  Establish  and  maintain  definitions  of  the  measures 
that  are  to  be  included  in  the  organization's  process 
performance  analyses. 

SP1.3  -  Establish  and  maintain  quantitative  objectives  for 
quality  and  process  performance  for  the  organization. 

SP1.4  -  Establish  and  maintain  the  organization's  process 
performance  baselines. 

SP1.5  -  Establish  and  maintain  the  process  performance 
models  for  the  organization's  set  of  standard  processes. 
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0  GomegjeMeflofi 

Software  Engineering  Institute 

Process  Performance  Models 

The  concept  of  a  process  performance  model  is  one  of  the  more 
challenging  things  to  master  in  getting  to  level  4.  The  utility  of 
these  models  evolves  significantly  over  time. 
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performance 

baselines 
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CarnegieMelkm 

Software  Engineering  Institute 

Quantitative  Project  Management 

The  purpose  of  the  Quantitative  Project 
Management  process  area  is  to  quantitatively 
manage  the  project’s  defined  process  to  achieve 
the  project’s  established  quality  and  process- 
performance  objectives. 
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GimegfeMeHoii 

Software  Engineering  Institute 


Using  Knowledge  of  History 
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CarnegieMelkm 
Software  Engineering  Institute 

Specific  Goals  for  QPM 

SG  1  -  Quantitatively  Manage  the  Project 

The  project  is  quantitatively  managed  using  quality  and 
process-performance  objectives. 

SG  2  -  Statistically  Manage  Subprocess  Performance 

The  performance  of  selected  subprocesses  within  the 
project's  defined  process  is  statistically  managed. 
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CarnegieMelkm 

Software  Engineering  Institute 

Specific  Practices  for  Goal  1 

SP1.1  -  Establish  and  maintain  the  project’s  quality 
and  process-performance  objectives. 

SP1.2  -  Select  the  subprocesses  that  compose  the 
project’s  defined  process  based  on  historical 
stability  and  capability  data. 

SP1.3  -  Select  the  subprocesses  of  the  project's 
defined  process  that  will  be  statistically  managed. 

SP1.4  -  Monitor  the  project  to  determine  whether  the 
project’s  objectives  for  quality  and  process 
performance  will  be  satisfied,  and  identify 
corrective  action  as  appropriate. 
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Carw-pe  Mellon 

Software  Engineering  Institute 

Quality  and  Process  Performance  Objectives 

Using  knowledge  of  the  business  context  for  the  project, 
and  the  past  performance  of  processes,  objectives  for  the 
project  are  set.  These  objectives  are  not  limited  to  the 
‘end-game’  but  provide  interim  performance  targets,  and 
are  subject  to  revision  with  new  knowledge. 
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CarnegieMelkm 

Software  Engineering  Institute 

Specific  Practices  for  Goal  1 

SP1.1  -  Establish  and  maintain  the  project’s  quality 
and  process-performance  objectives. 

SP1.2  -  Select  the  subprocesses  that  compose  the 
project’s  defined  process  based  on  historical 
stability  and  capability  data. 

SP1.3  -  Select  the  subprocesses  of  the  project's 
defined  process  that  will  be  statistically  managed. 

SP1.4  -  Monitor  the  project  to  determine  whether  the 
project’s  objectives  for  quality  and  process 
performance  will  be  satisfied,  and  identify 
corrective  action  as  appropriate. 
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GtmwskrlWeiJort 

Software  Engineering  Institute 


Select  Based  on  Stability  &  Capability 

Knowledge  about  the  performance  of  tailored  sets  of  processes  helps 
to  pro-actively  construct  the  project  defined  process  in  a  way  that 
increases  the  probability  of  meeting  the  objectives. 
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CarnegieMelkm 

Software  Engineering  Institute 

Specific  Practices  for  Goal  1 

SP1.1  -  Establish  and  maintain  the  project’s  quality 
and  process-performance  objectives. 

SP1.2  -  Select  the  subprocesses  that  compose  the 
project’s  defined  process  based  on  historical 
stability  and  capability  data. 

SP1.3  -  Select  the  subprocesses  of  the  project's 
defined  process  that  will  be  statistically  managed. 

SP1.4  -  Monitor  the  project  to  determine  whether  the 
project’s  objectives  for  quality  and  process 
performance  will  be  satisfied,  and  identify 
corrective  action  as  appropriate. 
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-  GtmttrkrMeUwt 

Software  Engineering  institute 


Select  for  Statistical  Management 


High-leverage  elements  of  the  constructed  process  are  identified  to 
provide  strategic  management  options  in  order  to  support  timely  and 
predictably  beneficial  control  of  project  performance. 
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CarnegieMelkm 

Software  Engineering  Institute 

Specific  Practices  for  Goal  1 

SP1.1  -  Establish  and  maintain  the  project’s  quality 
and  process-performance  objectives. 

SP1.2  -  Select  the  subprocesses  that  compose  the 
project’s  defined  process  based  on  historical 
stability  and  capability  data. 

SP1.3  -  Select  the  subprocesses  of  the  project's 
defined  process  that  will  be  statistically  managed. 

SP1.4  -  Monitor  the  project  to  determine  whether  the 
project’s  objectives  for  quality  and  process 
performance  will  be  satisfied,  and  identify 
corrective  action  as  appropriate. 
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^95=.  Carnegie  IWelten 

Software  Engineering  institute 


Monitor  Performance 

The  vital  few  elements  of  the  constructed  process  that  contribute  to 
predictable  performance  are  monitored.  This  is  done  in  the  context  of 
a  quantitative  (not  statistical)  framework  for  managing  the  project  as  a 
whole. 
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CarnegieMelkm 
Software  Engineering  Institute 

Specific  Goals  for  QPM 

SG  1  -  Quantitatively  Manage  the  Project 

The  project  is  quantitatively  managed  using  quality  and 
process-performance  objectives. 

SG  2  -  Statistically  Manage  Subprocess  Performance 

The  performance  of  selected  subprocesses  within  the 
project's  defined  process  is  statistically  managed. 
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CarnegieMelkm 
Software  Engineering  Institute 

Specific  Practices  for  Goal  2 

SP2.1  -  Select  the  measures  and  analytic  techniques  to 
be  used  in  statistically  managing  the  selected 
subprocesses. 

SP2.2  -  Establish  and  maintain  an  understanding  of  the 
variation  of  the  selected  subprocesses  using  the 
selected  measures  and  analytic  techniques. 

SP2.3  -  Monitor  the  performance  of  the  selected 

subprocesses  to  determine  their  capability  to  satisfy 
their  quality  and  process-performance  objectives, 
and  identify  corrective  action  as  necessary. 

SP2.4  -  Record  statistical  and  quality  management  data 
in  the  organization’s  measurement  repository. 
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Selecting  Measures  &  Techniques 

More  than  one  measure  is  typically  needed  to  characterize  the 
performance  of  any  process  we  care  about.  Multiple  analytic 
techniques  are  typically  used  to  understand  performance. 


Quality,  Productivity, 
Cycle  Time,  Quality 


Y  =  mX  +  ft 
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Specific  Practices  for  Goal  2 

SP2.1  -  Select  the  measures  and  analytic  techniques  to 
be  used  in  statistically  managing  the  selected 
subprocesses. 

SP2.2  -  Establish  and  maintain  an  understanding  of  the 
variation  of  the  selected  subprocesses  using  the 
selected  measures  and  analytic  techniques. 

SP2.3  -  Monitor  the  performance  of  the  selected 

subprocesses  to  determine  their  capability  to  satisfy 
their  quality  and  process-performance  objectives, 
and  identify  corrective  action  as  necessary. 

SP2.4  -  Record  statistical  and  quality  management  data 
in  the  organization’s  measurement  repository. 


©  2005  by  Carnegie  Mellon  University 


page  43 


CarnegieMeUan 
Software  Engineering  Institute 

Maintain  Understanding  of  Variation 

Knowledge  of  variation  may  start  with  historical  performance 
baselines,  but  becomes  more  precise  with  experience.  Control 
limits  from  the  past  may  serve  as  initial  specification  limits. 
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Specific  Practices  for  Goal  2 

SP2.1  -  Select  the  measures  and  analytic  techniques  to 
be  used  in  statistically  managing  the  selected 
subprocesses. 

SP2.2  -  Establish  and  maintain  an  understanding  of  the 
variation  of  the  selected  subprocesses  using  the 
selected  measures  and  analytic  techniques. 

SP2.3  -  Monitor  the  performance  of  the  selected 

subprocesses  to  determine  their  capability  to  satisfy 
their  quality  and  process-performance  objectives, 
and  identify  corrective  action  as  necessary. 

SP2.4  -  Record  statistical  and  quality  management  data 
in  the  organization’s  measurement  repository. 


©  2005  by  Carnegie  Mellon  University 


page  45 


#  Defects 
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Monitor  Capability  To  Meet  Objectives 


Tracking  Defect  Introduction  &  Detection 


Testing 
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Specific  Practices  for  Goal  2 

SP2.1  -  Select  the  measures  and  analytic  techniques  to 
be  used  in  statistically  managing  the  selected 
subprocesses. 

SP2.2  -  Establish  and  maintain  an  understanding  of  the 
variation  of  the  selected  subprocesses  using  the 
selected  measures  and  analytic  techniques. 

SP2.3  -  Monitor  the  performance  of  the  selected 

subprocesses  to  determine  their  capability  to  satisfy 
their  quality  and  process-performance  objectives, 
and  identify  corrective  action  as  necessary. 

SP2.4  -  Record  statistical  and  quality  management  data 
in  the  organization’s  measurement  repository. 
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Record  Management  Data 


Capturing  data,  along  with  an  adequate 
understanding  of  the  context  from  which 
they  arise,  is  also  process  to  be 
managed  carefully. 
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Maturity  Level  5  at  a  Glance 


A  profound  understanding  of  the  performance  of  time-tested 
processes  and  technology  supports  strategic  analysis  and 
improvement  within  the  context  of  a  quantitative  framework. 

Purposeful  changes  are  planned  and  deployed  using  techniques 
that  manage  risk  and  support  demonstrable  improvement. 
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Organizational  Innovation  and  Deployment 


The  purpose  of  Organizational  Innovation  and 
Deployment  is  to  select  and  deploy  incremental 
and  innovative  improvements  that  measurably 
improve  the  organization's  processes  and 
technologies.  The  improvements  support  the 
organization's  quality  and  process-performance 
objectives  as  derived  from  the  organization's 
business  objectives. 
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Specific  Goals  for  OID 

SG  1  -  Select  Improvements 

Process  and  technology  improvements  that 
contribute  to  meeting  quality  and  process- 
performance  objectives  are  selected 

SG  2  -  Deploy  Improvements 

Measurable  improvements  to  the  organization’s 
processes  and  technologies  are  continually  and 
systematically  deployed 
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Specific  Practices  for  Goal  1 

SP1.1  -  Collect  and  analyze  process-  and  technology- 
improvement  proposals 

SP1.2  -  Identify  and  analyze  innovative  improvements 
that  could  increase  the  organization’s  quality  and 
process  performance 

SP1.3  -  Pilot  process  and  technology  improvements  to 
select  which  ones  to  implement 

SP1.4  -  Select  process-  and  technology-improvement 
proposals  for  deployment  across  the  organization 
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Collect  and  analyze  process-  and 
technology-improvement  proposals 


Some  of  the  improvement 
proposals  focus  on  evolving  the 
capability  of  the  processes  or 
technology,  while  other 
proposals  tend  to  be  more 
revolutionary.  We’d  expect 
these  to  be  handled  differently. 
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Specific  Practices  for  Goal  1 

SP1.1  -  Collect  and  analyze  process-  and  technology- 
improvement  proposals 

SP1.2  -  Identify  and  analyze  innovative  improvements 
that  could  increase  the  organization’s  quality  and 
process  performance 

SP1.3  -  Pilot  process  and  technology  improvements  to 
select  which  ones  to  implement 

SP1.4  -  Select  process-  and  technology-improvement 
proposals  for  deployment  across  the  organization 
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Identify  and  analyze  innovative 
improvements  that  could  increase  the 
organization’s  quality  and  process 
performance. 

Improvements  are  purposefully 
sought,  not  just  passively 
received. 

Practices  for  documenting  and 
evaluating  proposals  may  be 
similar  to  those  described  in  the 
previous  SP,  but  the  activity 
described  here  is  initiated 
differently. 
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Specific  Practices  for  Goal  1 

SP1.1  -  Collect  and  analyze  process-  and  technology- 
improvement  proposals 

SP1.2  -  Identify  and  analyze  innovative  improvements 
that  could  increase  the  organization’s  quality  and 
process  performance 

SP1.3  -  Pilot  process  and  technology  improvements  to 
select  which  ones  to  implement 

SP1.4  -  Select  process-  and  technology-improvement 
proposals  for  deployment  across  the  organization 
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Pilot  process  and  technology  improvements 
to  select  which  ones  to  implement 


Piloting  process  &  technology 
innovations  is  more  than  a 
“feasibility  study.” 

Expectations  for  performance 
are  established  and  measured 
to  project  benefits. 

Pilot  studies  are  investments. 
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Specific  Practices  for  Goal  1 

SP1.1  -  Collect  and  analyze  process-  and  technology- 
improvement  proposals 

SP1.2  -  Identify  and  analyze  innovative  improvements 
that  could  increase  the  organization’s  quality  and 
process  performance 

SP1.3  -  Pilot  process  and  technology  improvements  to 
select  which  ones  to  implement 

SP1.4  -  Select  process-  and  technology-improvement 
proposals  for  deployment  across  the  organization 
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Select  process-  and  technology-improvement 
proposals  for  deployment  across  the 
organization 


Improvements  identified  in  this 
context  are  ones  that  warrant 
prioritization,  ROI  analysis,  and 
consideration  of  benefits  on  a 
more  broad  scale  than  a  single 
project’s  timeline  or 
performance. 
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Specific  Goals  for  OID 

SG  1  -  Select  Improvements 

Process  and  technology  improvements  that 
contribute  to  meeting  quality  and  process- 
performance  objectives  are  selected 

SG  2  -  Deploy  Improvements 

Measurable  improvements  to  the  organization’s 
processes  and  technologies  are  continually  and 
systematically  deployed 
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Specific  Practices  for  Goal  2 

SP2.1  -  Establish  and  maintain  the  plans  for  deploying 
the  selected  process  and  technology 
improvements 

SP2.2  -  Manage  the  deployment  of  the  selected 
process  and  technology  improvements 

SP2.3  -  Measure  the  effects  of  the  deployed  process 
and  technology  improvements 
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Establish  and  maintain  the  plans  for 
deploying  the  selected  process  and 
technology  improvements. 

This  practice  does  overlap  with 
Generic  Practice  2.2,  but  there  are 
unique  attributes  of  some  process 
or  technology  changes  that  require 
a  different  type  of  planning. 

Things  to  consider: 

•  Customization  of  technology 

•  Changes  needed  for  deployment 

•  Addressing  barriers 

•  Unique  stakeholders 
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Specific  Practices  for  Goal  2 

SP2.1  -  Establish  and  maintain  the  plans  for  deploying 
the  selected  process  and  technology 
improvements 

SP2.2  -  Manage  the  deployment  of  the  selected 
process  and  technology  improvements 

SP2.3  -  Measure  the  effects  of  the  deployed  process 
and  technology  improvements 
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Manage  the  deployment  of  the  selected 
process  and  technology  improvements. 


The  context  of  a  defined  and 
quantitatively  managed  process 
provides  an  effective  basis  for 
understanding  the  impact  of  a 
change.  This  involves  getting 
insight  prior  to  the  time  when  a 
“return  on  investment”  can  be 
computed. 
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Specific  Practices  for  Goal  2 

SP2.1  -  Establish  and  maintain  the  plans  for  deploying 
the  selected  process  and  technology 
improvements 

SP2.2  -  Manage  the  deployment  of  the  selected 
process  and  technology  improvements 

SP2.3  -  Measure  the  effects  of  the  deployed  process 
and  technology  improvements 
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Measure  the  effects  of  the  deployed 
process  and  technology  improvements 


Simply  determining  that  the 
deployment  was  not  a  disaster 
is  not  sufficient. 

There  are  a  set  of  objectives 
and  plans  that  provide  the 
framework  for  measuring 
effects  against  estimates. 
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Causal  Analysis  and  Resolution 

The  purpose  of  Causal  Analysis  and  Resolution  is 
to  identify  causes  of  defects  and  other  problems 
and  take  action  to  prevent  them  from  occurring  in 
the  future. 
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Specific  Goals  for  CAR 

SG  1  -  Determine  Causes  of  Defects 

Root  causes  of  defects  and  other  problems  are 
systematically  determined 

SG  2  -  Address  Causes  of  Defects 

Root  causes  of  defects  and  other  problems  are 
systematically  addressed  to  prevent  their  future 
occurrence 
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Specific  Practices  for  Goal  1 

SP1.1  -  Select  the  defects  and  other  problems  for 
analysis 

SP1 .2  -  Perform  causal  analysis  of  selected  defects 
and  other  problems  and  propose  actions  to 
address  them 
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Select  the  defects  and  other  problems  for 
analysis 


Performing  CAR  on  every 
defect  or  problem  is  potentially 
very  wasteful. 

The  potential  return  on 
addressing  types  of  defects 
and  problems  drives  the  choice. 
This  looks  a  lot  like  DAR  in 
practice. 
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Specific  Practices  for  Goal  1 

SP1.1  -  Select  the  defects  and  other  problems  for 
analysis 

SP1 .2  -  Perform  causal  analysis  of  selected  defects 
and  other  problems  and  propose  actions  to 
address  them 
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Perform  causal  analysis  of  selected 
defects  and  other  problems  and  propose 
actions  to  address  them 


Causal  analysis  implies  gaining 
insight  about  the  system  of 
events  that  led  to  the  identified 
defects  or  problems. 

This  leads  to  addressing  the 
potential  for  future  defects  and 
problems  of  the  same  type,  not 
just  addressing  a  single  issue 
at  one  point  in  time. 
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Specific  Practices  for  Goal  2 

SP2.1  -  Implement  the  selected  action  proposals  that 
were  developed  in  causal  analysis 

SP2.2  -  Evaluate  the  effect  of  changes  on  process 
performance 

SP2.3  -  Record  causal  analysis  and  resolution  data  for 
use  across  the  project  and  organization 
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Implement  the  selected  action  proposals 
that  were  developed  in  causal  analysis 


This  practice  overlaps  with  the 
01 D  practices  in  terms  of  how  it 
can  be  realized. 

There  is  a  more  routine  aspect 
to  this  practice,  however,  that 
may  be  evident  at  a  local  level: 

•  identifying  related  defects 

•  searching  for  similar  causes 

The  process  of  prioritizing 
actions  draws  on  a  DAR-like 
mentality. 
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Specific  Practices  for  Goal  2 

SP2.1  -  Implement  the  selected  action  proposals  that 
were  developed  in  causal  analysis 

SP2.2  -  Evaluate  the  effect  of  changes  on  process 
performance 

SP2.3  -  Record  causal  analysis  and  resolution  data  for 
use  across  the  project  and  organization 


©  2005  by  Carnegie  Mellon  University 


page  79 


Gxraegie  Mellon 

Software  Engineering  Institute 

Evaluate  the  effect  of  changes  on 
process  performance 


The  intent  is  to  view  the  impact 
for  on-going  performance  of  the 
related  process  or  technology, 
not  a  one-time  “ROI.” 

Need  to  answer  questions  like 
“is  a  5%  performance  change  an 
improvement,  or  just  part  of  the 
normal  fluctuation?” 
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Specific  Practices  for  Goal  2 

SP2.1  -  Implement  the  selected  action  proposals  that 
were  developed  in  causal  analysis 

SP2.2  -  Evaluate  the  effect  of  changes  on  process 
performance 

SP2.3  -  Record  causal  analysis  and  resolution  data  for 
use  across  the  project  and  organization 
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Record  causal  analysis  and  resolution 
data  for  use  across  the  project  and 
organization 


A  more  detailed  understanding 
the  value  of  information  is  one 
of  the  most  notable  attributes  of 
highly  mature  organizations. 
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Schedule  For  The  Day 


Start 

Finish 

Duration 

Topic 

8:30 

9:00 

30  min 

Introduction 

9:00 

10:00 

60  min 

Level  4  Practices 

10:00 

10:30 

30  min 

Break 

10:30 

11:30 

60  min 

Level  5  Practices 

11:30 

h  o-nn 

12:00 

a  nn 

30  min 

Prepare  for  Break  Outs 

1  II  n 

\Z.  UU 

1:00 

1  .UU 

2:30 

ou  min 

90  min 

Luncn 

Subgroup  Work  Session 

O.  AA 

2:30 

3.00 

30  min 

Break 

3:00 

3:30 

30  min 

Prepare  Report  Out 

3:30 

5:00 

90  min 

Reports  and  Discussion 
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